Subject: stuff I promised

From: "Peter W. Gayek" <[email-masked]>
Date: Fri, 21 Oct 94 15:05:03 EDT

Here's my input on the work items I took at AIW6.  Deirdre's 10/17
minutes had my name down for a 3rd item called "Directory Activities"
which I think was really Paul Brittain's work item.  (the names Peter
and Paul are frequently interchanged - I've always wondered if that's
because of the apostolic relationship or the singing group .....)

ITEM 1 ----------
"Transport type objects" - I think this meant I should suggest some
TCP-specific candidate objects.  Here are all the things I could
think of including, then I will tell you which I think are worth
including.

  Max segment size (bytes) - MSS this node is willing to receive

  Enable keepalive (yes/no) - whether to send keepalive messages
    I thinks this should be TCP-specific and not general because
    other transport types may not provide an option.

  Keepalive interval (seconds) - time between keepalive messages when
    no traffic flowing.  If we have this, we should have a value that
    means "no keepalive" and get rid of the enable object.

  Transmit buffer size (bytes) - using a model of a single send ring
    buffer per connection, how big can this be, i.e., how much unack'd
    data can TCP hold at one time.

  Receive buffer size (bytes) - using a model of a single rcv ring
    buffer per connection, how big can this be, i.e., how much data
    can TCP hold before it must completely close its window, if the appl
    isn't taking any data.  You could call this a "max rcv window size"
    to be more general, but then there would be no direct corollary on
    the send side.

  Receive window size (bytes) - actual operational receive window
    size (this would have to be on a partner basis)

These objects could be on a partner basis, or a box basis.  If on
a partner basis, implementations which allow TCP connections from
undefined partners would still need a "box" set to serve as defaults
for the undefined partner connections.  Note that for all the transmit/
receive stuff, I am assuming we would manage only the part of each
of the two TCP connections that really gets used (transmit stuff for
our 2067-port connection, receive stuff for our 2065-port connection).

And now for my opinions.  As a first cut, I would vote for only 2
TCP-specific objects.  I would have these on a partner basis plus
have one set for the box (so N partners means 2(N+1) objects).
I would make all these administrative objects, with no operational
versions.  Any changes take effect only for new TCP connections.
These objects I would suggest are:
   Max segment size (integer, allow 512 - 65535 bytes)
   Keepalive interval (integer, allow 0 - 1800 seconds where zero
     means "no keepalive")
The buffer sizes seem to me to be too implementation-specific, and
I don't think we should let an operator mess with the real dynamically
changing receive window size for an active connection.

ITEM 2 ---------
"Transport Control Traffic" - I was to give some rules for what was
included in various counters.  Here's my cut:

dlswTConnInDataPkts
  The number of SSP messages of type DGRMFRAME, INFOFRAME, or DATAFRAME
  received on this tranport connection.
dlswTConnOutDataPkts
  The number of SSP messages of type DGRMFRAME, INFOFRAME, or DATAFRAME
  transmitted on this tranport connection.
dlswTConnInDataOctets
  The number of bytes in SSP messages of type DGRMFRAME, INFOFRAME,
  or DATAFRAME received on this tranport connection.  Each message is
  counted starting with the first byte following the SSP message header.
dlswTConnOutDataOctets
  The number of bytes in SSP messages of type DGRMFRAME, INFOFRAME,
  or DATAFRAME transmitted on this tranport connection.  Each message is
  counted starting with the first byte following the SSP message header.
dlswTConnInCntlPkts
  The number of SSP messages received on this tranport connection
  which were not of type DGRMFRAME, INFOFRAME, or DATAFRAME.
dlswTConnOutCntlPkts
  The number of SSP messages transmitted on this tranport connection
  which were not of type DGRMFRAME, INFOFRAME, or DATAFRAME.

By this definition, there are 21 control message types, so I thought
it was best not to list them by name.

Peter